Very nice! Do you expect to have visible performance improvements from this?

Very nice! Do you expect to have visible performance improvements from this?

Not at all. But I care about resources (which tend to blow up in completely unrelated situations, and is hard to debug) and mill server processes can last very long, so it may make some difference. It's more the fact that we now support resource cleanup, and Module (worker) authors will look into existing code as a guide how to implement their stuff. If they see sme cleanup code, they hopefully learn that it is something worth thinking about.

@lolgab Do you have an idea how we can implement the VizWorker cleanup in a binary compatible way? It's probably the only worker really worth to cleanup, as it starts (and never stops) a background thread. Or do you think we can make an exception and just ignore the binary breakage here? See my second commit as a first attempt.

The only idea I have is to define a new vizWorker and deprecate worker. In 0.11 we can delete worker and in 0.12 we can rename vizWorker back to worker.

You can extract the implementation of the worker in a private function.

Ok, I will address the VisualizeModule.worker in a different PR.